IEEE P802.11
Wireless LANs

OBSS Requirements

Date:  2008-07-28

Author(s):

Name

Affiliation

Address

Phone

email

Alex Ashley

NDS Ltd

One London Road, Staines, Middlesex, TW18 4EX, UK

+44 1784 848770

[email-masked]

Brian Hart

Cisco Systems

170 West Tasman Drive, San Jose, CA 95134

408-526-3346

[email-masked]

Graham Smith

DSP Group

2491 Sunrise Blvd, #100, Rancho Cordova CA 95742

916 851 9191 x209

[email-masked]

Abstract

During the July 802.11 meeting in Denver, document 08-0758 was presented, which contained some proposed technical requirements for a solution to the overlapping BSS problem. Following this as straw poll was taken with the question “Should the OBSS Requirements presentation (08/765r1) be used as the starting point for a formally written OBSS Requirements document?” To which the result was 19 yes, 0 no, 6 abstain.

Another document, 08-0864 was also presented that described a scenario where a chain or loop of overlapping BSS could occur. It was subsequently agreed that this should also be added to the OBSS requirements document.

This document contains the requirements from 08-0758 and 08-0864 plus the changes to 08-0758 discussed by the 11aa task group and recorded in document 08-0758.

Introduction

The P802.11aa PAR has an item in its scope for “Increased robustness in overlapping BSS environments, without the requirement for a centralised management entity”.  An overlapping BSS is defined as two or more wireless networksBSSs that are operating on the centre same centre frequency in radio range of each other.

This document contains a list of the technical requirements for improved overlapping BSS coexistence against which proposals can be evaluated.

Obviously it is preferable to avoid the overlapping BSS condition with appropriate use of techniques such as channel selection and transmit power control. The scope of this requirements document for improving OBSS coexistence does not include techniques to avoid BSS overlap.

In 2.4 GHz band, overlapping BSS is routine. OBSS at 5 GHz is much less likely, but still occurs due to:

§40 MHz operation

§DFS not implemented or certified (e.g. IBSS)

§Poor channel selection

§Moving APs

§Nearby radar

Examples

The above diagrams represent idealized versions of overlapping BSS and in the real world OBSSs are more complex because the coverage of a BSS is not uniform. Also, an OBSS condition can change over time due to factors such as use of transmit power control, movement or changes in radio path propagation.

The above conditions can occur simultaneously in combination, such as in the example below:

1.1.                          Figure 13 - Example of a chain of overlapping BSS

Criteria for evaluating Overlapping BSS proposals

The criteria below will be used to evaluate OBSS proposals.following items describe technical requirements that the 802.11aa task group intends to fulfil in its solution to improving robustness in overlapping BSS environments.

1.         Enables improved Quality of Service

1.1.                          When a video transport stream has been accepted, additional traffic from other BSSs should not cause the video transport stream it to stopfail to meet its QoS requirements.

1.2.                          It is not required to provide OBSS protection for video transport streams that have not used an admission control protocol.

2.1.Number of Overlapping Networks

1.3.                          ShallShould support improve network performance when there are 2 overlapping BSS.

1.1.                     Should support 3 overlapping BSS

1.4.                          Shall support the scenario where one STA overlaps multiple BSSs

1.1.

3.2.         Contention based medium access protocols

2.1.                          Pre-11aa EDCA-AC admissions should shall be preserved

2.2.                          Shall support a mechanism to avoid beacon collision and multicast collision

4.3.         Controlled medium access protocols

3.1.                          Shall support protection for controlled medium access reservations

3.2.                          Shall support TBTT / DTIM adjustmenta mechanism to avoid beacon collision and multicast collision

5.4.         Inter-AP communication for improved OBSS robustness

4.1.                          If inter-AP communication is required, it shall be possible to perform this communication using the WM.

4.2.                          If inter-AP communication is required, it should be possible to perform this communication using the DS.

1.1.                     Shall be possible for APs to communicate via the WM when both APs in range of each other

1.1.                     Should be possible for APs to communicate via the wired DS

May be possible via WM when APs not in range

4.3.                          Shall be resistant to denial of service and other attacks and provide mitigation against such attacks.

6.5.         Management

5.1.                          Shall not mandate that an AP to be configured as the supervisor controller

5.2.                          If the solution requires an AP to be automatically chosen as supervisor, it shall be robust to signal fade and AP removal

May support configuration of a supervisor controller for enterprise use

Shall not mandate pre-shared configuration

5.3.                          Shall provide a mechanism to control the dynamic aspects of the OBSS solution

7.6.         Dynamic

6.1.                          User experience sShall be robust invarient to the order in which APs are switched on or off

6.2.                          Removal of an AP shall not cause video streams in other BSSs to terminate

6.3.                          Should Shall support dynamic stream creation & and deletion

Maintains current 802.11 levels of privacy

6.4.                          Shall not require detailed information about stream reservations to be exchanged between APs

6.5.                          Shall maintain current 802.11 levels of privacy (Note: may want to remove this, as it is covered by previous item)

8.7.         Fairness (cooperation) / Quality of Service / System Performance and Priority[AA1]

7.1.                          For each 802.11 medium access mechanism, tThe right to access the WM shall be comparible with the current levels of fairness provided by the 802.11 specification.

7.2.                          If the solution requires an AP to be chosen as supervisor, the act of providing the supervisor role does not gain increased priority in medium time allocation over other overlapping BSS.

7.3.                          The Actual division of time might not be fairmay differ in each BSS, due to differing loads in each BSS.

7.4.                          The solution should include mechanisms to limit allocations based upon total capacity of the WM.

7.5.                          The solution must include mechanisms to enable APs to communicate BSS loads with each other with the intent to share access to the WM.

7.6.                          The solution should not significantly reduce the total system throughput nor significantly increase the delay or jitter compared to legacy systems.

9.8.         ESS / BSS

8.1.                          The solution shall support overlapping BSS that are in the same ESS or a different ESS.

10.9.    Security

9.1.                          The solution sShall not require the reduction in the security policy of a BSS

9.2.                          The solution sShall be robust to attacks from rogue AP / non-AP STA

9.3.                          The solution Does must not create a new denial of service technique

11.10.                       Compatible with legacy non-11aa equipment

10.1.                       The solution sShould not require non-AP STA modification

10.2.                       The solution sShall be tolerant of legacy non-AP STAs

10.3.                       The solution sShould be tolerant of legacy APs

10.4.                       The solution should improve the performance of an 11aa BSS in the presence of overlapping non-11aa BSSs without adversely degrading the performance of the legacy BSSs.

12.11.                       Frequency bands

11.1.                       The solution sShall support 2.4GHz and 5GHz

11.2.                       The solution sShall support 20 and 40MHz channel widths

11.3.                       The solution sShall support 5 and 10 MHz channels when all BSSs are using the same channel width.

12.            Diagnostics

12.1.                       Shall provide a mechanism to provide metrics on the current performance of the OBSS solution

References:

[AA1]Need to choose section title.